Technical Q&A's

QD 31 - Necessity of Calling PrJobDialog (1-Nov-95)

Q Do I need to call PrJobDialog() to print a document? Why?

A Yes. In Inside Macintosh:Imaging with QuickDraw, pages 9-18 and 9-19 it states:

"When writing an application, the code you provide that handles printing is referred to as the _printing loop_. A printing loop calls all the Printing Manager routines necessary to print a document. In general, a printing loop must do the following tasks:
[...]

It must display the job dialog box as appropriate by using the PrJobDialog function or, for a customized job dialog box, the PrDlgMain function. (When the user is printing from the Finder, display the job dialog box only once, and then use the PrJobMerge procedure to apply the information from this dialog box to any other documents selected by the user.
[...]"

The reason for this is that many drivers (most notably LaserWriter 8) don't initialize the job-specific settings until PrJobInit is called. Without this call, they fall back on the default, which is usually stored in the driver in the PREC 0 resource.

The normal definition of the PREC (which maps to a TPrint structure) doesn't have as much space as LaserWriter 8 needs. Because of this, LaserWriter 8 stores some settings in this PREC 0 resource, and stores others in the "LaserWriter 8 Prefs" file. This separation of LaserWriter settings can wreak havoc on a job run without the PrJobDialog call.

If you absolutely MUST not display the PrJob dialog, there are two ways to work around it. These are not supported methods, and by using either of them you've just made your application hostile to QuickDraw GX and to Copland.

Call PrJobDialog either when you make your final build, or have users do it as part of their preferences (or both), and save the resulting print record. Every time you print, merge that print record in with a call to PrJobMerge. This way each document can have its own page setup, accomodating things like printing on A4 paper instead of letter.
"Display" the dialog, but never let the user see it. You can accomplish this by calling PrJobInit, moving the resulting dialog offscreen, patching ModalDialog, and calling PrDlgMain. Your patched version of ModalDialog can return a 1 for the OK button immediately, and you've got the added benefit of actually calling all the code, and having a relatively normal print loop.

See Inside Macintosh: Imaging with QuickDraw, Chapter 9.

Technical Support
Technical Q&As
Previous Question | Contents | Next Question